Conversation
Adds a comment system for video editing. - Comments.tsx: Renders a scrollable list of comments with nested replies, timestamps, and status badges. Includes forms to add comments (with a required reason dropdown), reply, delete, and toggle resolved status. - commentSlice.ts: Manages local state for adding, deleting, and updating comments. Tracks uncommitted changes (\hasChanges\) and handles temporary local IDs.
|
Form submitted - G |
|
This pull request is deployed at test.editor.opencast.org/1685/2026-03-27_08-12-36/ . |
|
For those curious, I have confirmed that this is a student at Munster. |
|
Hi @Bennit99 |
mtneug
left a comment
There was a problem hiding this comment.
Works as expected. Only some small comments from my side. Since I don't really work on the front-end, it would be great to also get a review from someone more familiar with the codebase.
This reverts commit 9dd6ba9b8bf6749c0fa5218696fa78a597f05605.
Co-authored-by: Matthias Neugebauer <mtneug@mailbox.org>
gregorydlogan
left a comment
There was a problem hiding this comment.
I'm not confident enough to review this properly. @Arnei can you, or delegate to someone who would be confident reviewing this?
| show = true | ||
|
|
||
| [comments] | ||
| show = false |
There was a problem hiding this comment.
This should probably be true, since this config is what's backing editor.opencast.org and we want to show off all of the bells and whistles.
Arnei
left a comment
There was a problem hiding this comment.
Overall this looks very good to me! The stuff below is all pretty nitpicky.
I think I might have liked it better if the component was not quite as monolithic and split into more components, but I can see why you did that and it should not cause any trouble.
One thing I would like to see changed is the use of colors, namely I think there should be less of them. The color scheme of the editor is decidedly grayscale. Colors should not be used to make the ui look nice, but to explicitly draw the users attention to certain elements. For example, red signifies danger, so having the delete buttons in red makes sense to me. But the Submit/Reply/Cancel buttons at the bottom right do not require any color in my opinion. I'd say the same goes for the badges. Here there is also the additional issue that their color contrast to the background is quite low in light mode, making them hard to read.
| }, | ||
|
|
||
| "comments": { | ||
| "no-comments": "No comments yet. Be the first to comment!", |
There was a problem hiding this comment.
Would make sense for a social media post or similar, but there is no reason to incentivize posting comments in Opencast. I think "No comments yet." is enough.
|
|
||
| // Handlers | ||
| const handleSaveComment = () => { | ||
| if (!settings.id || !newCommentText || !commentReason) { |
There was a problem hiding this comment.
Not like it is causing problems, but why are we checking for settings.id in the save handlers?
| // Modern scrollbar styling | ||
| "&::-webkit-scrollbar": { | ||
| width: "8px", | ||
| background: theme.background, | ||
| }, | ||
| "&::-webkit-scrollbar-thumb": { | ||
| background: theme.text, | ||
| borderRadius: "5px", | ||
| }, |
There was a problem hiding this comment.
This is not bad or anything, but definitely different from every other scrollbar in the editor. I don't think the stylistic inconsistency is worth it?
|
|
||
| return ( | ||
| <div css={containerStyle}> | ||
| <h2 css={titleStyleBold(theme)}>{t("mainMenu.comments-button")}</h2> |
There was a problem hiding this comment.
For consistency with other views, could you center the title?
| gap: "6px", | ||
| fontSize: "0.9em", | ||
| color: theme.text, | ||
| opacity: 0.7, |
There was a problem hiding this comment.
Having a fixed opacity can lead to low contrast in the high-contrast color modes. You'll likely either want to make your opacity level a theme variable, or adjust your text color.
| <Select<{ value: string; label: string }> | ||
| styles={selectFieldStyle(theme)} | ||
| value={commentReason | ||
| ? { value: commentReason, label: t(`comments.reasons.${commentReason}` as never) } |
There was a problem hiding this comment.
The more semantically correct type here would be ParseKeys from i18next. Might also make sense to type commentReason in a way that no typecast is needed? (same for the other two occurences of this)
| "wrong_series_publication": "Wrong series or publication channel", | ||
| "wrong_workflow": "Wrong workflow", | ||
| "processing_failure": "Processing failure", | ||
| "admin_ui_notes": "Notes in Admin UI" |
There was a problem hiding this comment.
I think this should be adminui_notes?
| id: nanoid(), | ||
| creationDate: new Date().toISOString(), | ||
| author: "", // Backend stamps the actual author via SecurityService | ||
| displayName: "", |
There was a problem hiding this comment.
Any chance we could have the display name of the current user here? It is a bit disorienting that new comments do not have the name of a user associated with them in the ui.
|
FYI: I will take over the development of this PR as @Bennit99 sadly no longer works as a student for us. It might take some time, but I will work on the mentioned issues. |
Adds a comment system for video editing like in the old admin UI.
Comments.tsx: Renders a scrollable list of comments with nested replies, timestamps, and status badges. Includes forms to add comments (with a required reason dropdown), reply, delete, and toggle resolved status.
commentSlice.ts: Manages local state for adding, deleting, and updating comments. Tracks uncommitted changes hasChanges and handles temporary local IDs.
Also configure a temporary vite dev proxy to bypass CORS for testing with loacal opencast instance
For testing create and delete some comments and replies
Issue: Feature Request: Make comments available
backend PR